5.3.3 APPX Application Design Manual

+ Chapter 1-1: Overview of Application Design
+ Chapter 1-2: Getting Started
- Chapter 1-3: Data Dictionary
+ Chapter 1-4: Understanding Process Design
+ Chapter 1-5: Interprocess Communication
+ Chapter 1-6: Customizing Your Application
+ Chapter 1-7: The Documentation Facility
+ Chapter 1-8: Application Design Tools
+ Chapter 2-1: Data Dictionary Overview
+ Chapter 2-2: Data Dictionary Concepts
+ Chapter 2-3: Domains
+ Chapter 2-4: Files and Fields
+ Chapter 2-5: Work Fields
+ Chapter 3-1: Overview of APPX Processes
+ Chapter 3-2: Getting Started
+ Chapter 3-3: Process Definition
+ Chapter 3-4: Menu Processes
+ Chapter 3-5: Job Processes
+ Chapter 3-6: Input Processes
+ Chapter 3-7: Output Processes
+ Chapter 3-8: Update Processes
+ Chapter 3-9: Query Processes
+ Chapter 3-10: Inquiry Processes
+ Chapter 3-11: Status Processes
+ Chapter 3-12: Subroutine Processes
+ Chapter 3-13: Table Processes
+ Chapter 3-14: Automatic and Optional Children
+ Chapter 3-15: Using the Image Editor
+ Chapter 3-16: Using GUI Features of the Image Editor
+ Chapter 3-17: Using Event Points
+ Chapter 4-1: ILF Integration
+ Chapter 4-2: True/False Status Indicators
+ Chapter 4-3: Specifying Statements
+ Chapter 4-4: The ILF Editor
+ Chapter 4-5: The Appx ILF Debugger
+ Chapter 4-6: ILF Keyword Reference
+ Chapter 4-7: Predefined Fields
+ Chapter 4-8: Runtime Subroutine's and Predefined Processes
+ Chapter 4-9: Appx Chart Director API

Chapter 1-3: Data Dictionary

Characteristics of the APPX Data Dictionary


The data dictionary is active in that its specifications are used by, and place real-time restrictions on, both designers creating applications and users operating them. For example, assume you defined a numeric, five-digit CUSTOMER ID field. APPX uses the length specification to provide the proper mask when a designer paints the field onto an input image. APPX also uses data dictionary specifications as a basis for validation when an image is executed. The system displays an error message if a user attempts to enter a non-numeric character into the CUSTOMER ID field. An active data dictionary maximizes consistency, productivity, and integration. It minimizes the chance for error, both when designing and using applications.

To enhance performance,you process APPX's dictionary before using it. Specifications entered into the data dictionary are translated into a format more directly usable by APPX during process execution. The process also searches for logic errors (such as invalid key definitions or illegal record lengths), constructs a default value record for each file, computes field lengths, establishes the starting position for each field within a record, and determines whether or not the changes may affect the structure of existing data files.

The dictionary provides for integrated documentation, including entry screens for online help text and printed technical documentation.

To ensure integrity, the dictionary is automatically monitored for structural changes. Examples of structural changes include adding a field to a file or expanding the length of an existing field. By contrast, changing the standard column heading for a field is not a structural change. Whether you make a structural or non-structural change to the dictionary, all processes that reference changed elements are automatically updated. APPX flags existing files that require restructuring, and the restructure facility (available as an option on the File Management menu) enables your database administrator to convert them to the new structure. This facility reduces the need to 'freeze' the file structures in applications. Data dictionary changes requiring restructure should be made when the file is not in active use by the end user.

Application Design Manual                                         "Powered by Appx Software"

34

©2006 By APPX Software, Inc. All Rights Reserved